RabbitMQ在国内为什么没有那么流行? 您所在的位置:网站首页 rabbitmq return机制 RabbitMQ在国内为什么没有那么流行?

RabbitMQ在国内为什么没有那么流行?

#RabbitMQ在国内为什么没有那么流行?| 来源: 网络整理| 查看: 265

我给你讲一个笑话,我以前做过一个云端业务服务产品,当时就是用大厂云,不过随着业务需求增加,又要在国企云部署。我就不解,问了下boss,统一部署在一个云不好吗?boss说业务需要,云厂商要拼业绩,有其他深度合作。

好,我忍了,双云交互,总要有个mq把,rabbitmq我认为更合适一些,总之要做关键业务的消息传递,我给boss提出来,架构需要调整,双云走mq比较稳妥。

你猜boss怎么回复我的? 你把事情搞复杂了,要简单的来,我问咋简单,boss说大厂云的数据库开放给国企云,国企云就部署微服务访问大厂云数据库。我都哭笑不得了,我说数据库暴露在互联网很危险,boss不屑的来了一句:你说的也太玄乎了!

有时候国内的架构师就得面对低成本,又怕事的小企业主思维,大量的长尾软件公司都差不多,你咋用更复杂的mq业务架构。kafka之所以用得多,其实大部分场景就是采集个日志。看不出高价值,也不是关键性业务,咋折腾都没人管。

更新部分:

评论中有朋友自信的认为公网暴露数据库,只要设置IP白名单就是安全的。

我就不在评论里说了,请先从整体架构看,再看技术细节,公网数据库一旦暴露,另一个云所有需要数据库访问的微服务群都需要能访问到,那么公网IP白名单会开很多,这是其一

这种架构一旦定型,是不是以后只要再加入个某云,甚至是企业私有云,或者是某个第三方系统对接,中心数据库都要在公网给所有外部访问开数据库白名单,这是其二

只要任意一台公网连接的机器被攻击,中心数据库就得完蛋,我就想问你不胆寒吗?

不要以为大厂的服务安全做得好,其他云,其他第三方系统就也没问题,IP包伪装我不清楚大厂是否能准确识别,仅从上述的架构走势,就是畸形的。作为架构师思考的不仅仅是当下该怎么办,而是要从整体观和发展趋势来看待问题和隐患。

还有评论说用mq是不是为了解决安全

另外我再重申一遍,使用mq,跨越双云,甚至是多云,这是异构平台,进行业务数据同步,在网络环境不确定的情况下,比较合理的解决方案,减少公网同步双写调用的互相影响,公网之间的微服务互调,还存在挤占公网带宽的问题。

boss要求的数据库直接暴露在公网的解决方案,来最大化降低系统升级的成本,这是整个系统安全性的关键问题,跟用mq是不是为了安全没半毛钱关系。

继续更新,有评论说不要把安全说的那么绝对,也别认为MQ就能hold住。好,那我们把安全放到一边,不提了,MQ不用了,就按照boss的说法,数据库暴漏到公网,看看这个架构是个什么样子!

先看看原来的架构图:

我们可以看到红色圈中的API网关->微服务->数据库通讯交互,都是在一个内部高速、稳定且几乎不存在路由的网络中进行在线事务计算处理的请求响应过程中。

好,看看现在按照boss要求,用最简单的办法,数据库暴漏公网,第二个云只是部署所属区域服务范围的微服务。

红色线头代表的就是客户端发起请求,大厂云API网关就要通过公网反向代理到国企云的微服务,然后国企云的微服务做再通过公网同步访问大厂云的数据库做事务级处理。然后,再通过两次公网传输,把业务处理的数据响应给客户端。

这个架构还谈什么高并发、低延时、事务稳定、访问可靠;安全性更是致命,在这种纯粹拿公网赌命的架构下,这是平衡成本和技术的问题吗?

再次更新:

看来已经跑题很远了,索性再把我们业务的形态简单描述一下,摘自评论:

DB数据从规范讲就是要分开,各个区域存储各个的,但客户端业务是统一入口。可以这么去理解:App平台业务需要入驻很多商家,但某一个区域的的所有商家数据需要归另一个云的服务商所属机构总体所有并提供计算服务,当然实际业务不是电商。为什么要用mq,实际上的目标设计:api网关可以将客户端的请求调度到另一个国企云的api网关上去执行同类型微服务,并将数据存储在国企云,但是中心数据库还是在大厂云,仍然需要将国企云,甚至以后类似模式的分库数据通过mq的方式同步上来。另外中心数据库还要统一管理基础平台数据,任何的记录调整,都要通过mq分发到其他云的库中,防止各自为政的情况。

再次更新,那些评论说我有技术洁癖的,说互联网公开数据库端口可以通过技术保护措施的朋友们,看看这个顺丰删库事件吧!

这还是在正规的流程下,都会出现如此的删库错误,更何况,把数据库放置在公有环境,已经形成无法控制的网络边界局面,在任意跨域的白名单服务器上走一个Navicat,甚至是终端命令,就能因为失误把数据库中心搞垮,记好,是整个数据中心!千万别再说我预料要说的话:“做灾备呀?”,“再严格也会误操作啊”,“哪有绝对的安全啊”,"这种几率很小的",说这些话都属于不是自家事,不嫌事大!

还有mq就算也有安全风险,它总比数据库风险小吧!删了mq了,窃取mq数据了,这都好恢复,损失也是最小。而且mq只是通道,通道里的数据停留多少,都可以控制,还可以加密,例如为了安全,我控制mq通道数据就持久化一天,隔天就清理,难道我能把数据库中心隔天的数据清理吗?安全不仅仅来自外部,往往问题出在内部,所以数据中心的安全一定要用最小范围的思想来限定网络边界,就是为了可控!可控!可控!

最终更新:

最后的附图我才给出真正想达到的双云架构目标,如下图所示:无论在何地的用户使用客户端APP需要访问国企云所属区域的服务,都会通过一个API网关总入口重定向到国企云所在的网关上,那么之后的所有在线事务操作都是在云内部完成,这样就保证了各云的业务通讯独立性,不会像上面那个架构的通讯变成了拖着长长的尾巴。

国企云的区域数据库通过同步任务,将数据经过MQ上传至数据中心,这就是分布式架构中保证了业务数据的最终一致性。同理,数据中心下发基础数据的修改,必要情况下,下发过程可以配合临时停止国企云的网关服务,保证同步完成后再启用,实现分布式环境下,基础配置数据在不同云的强一致性。

订阅专栏:大数据/Java/Linux从零开始技术训练_守护石-CSDN博客



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有